In typical database systems, users store, update, and retrieve information by interacting with user applications ("clients"). The clients respond to the user's interaction by submitting commands to a database application responsible for maintaining the database (a "database server"). The database server responds to the commands by performing the specified actions on the database. To be correctly processed, the commands must comply with the database language that is supported by the database server. One popular database language is known as Structured Query Language (SQL).
Various access methods may be used to retrieve data from a database. The access methods used to retrieve data may significantly affect the speed of the retrieval and the amount of resources consumed during the retrieval process. Many access methods use indices to increase the speed of the data retrieval process. Typical database management systems have built-in support for a few standard types of access methods, such as access methods that use B+Trees and Hash Tables, that may be used when the key values belong to standard sets of data types, such as numbers, strings, etc. The access methods that are built-in to a database system are referred to herein as native access methods.
In recent years, databases are being used to store different types of data, such as text, spatial, image, video, and audio data. For many of these complex data types, the standard indexing techniques and access methods cannot readily be applied. To provide efficient data retrieval, many database systems that allow users to store complex data types attempt to provide access methods suitable for the complex data types. For example, R-trees are an efficient index mechanism for indexing spatial data. Therefore, a database system that allows users to store spatial data may include built-in support for R-tree access methods. However, attempts to provide native support for all types of access methods are unrealistic because it is not possible to foresee all possible types of complex data that clients may wish to store in a database, much less all types of access methods that one may wish to use with such data types.
According to one approach, clients may be designed to provide their own indexing mechanisms for data types that cannot use the native access methods of the database system. For example, assume that the native access methods of a database server do not include R-tree access methods. A client that uses spatial data would use the database server to store the spatial data in the database, but would maintain an R-tree index structure outside the database. The client would be responsible for maintaining and using the R-tree index outside of the database system environment, while the spatial data itself is maintained within the database environment.
Unfortunately, storing an index outside a database for data that is stored within a database has several significant disadvantages. Specifically, it is difficult to maintain consistency between external indices and the related relational data, support compound queries (involving tabular values and external indices), and to manage a system (backup, recovery, allocate storage, etc.) with multiple forms of persistent storage (files and databases).
Based on the foregoing, it is clearly desirable to provide a database server that supports arbitrary, user-defined data types. It is further desirable to provide a database server that may be extended to support non-native access methods while maintaining the index structures for the non-native access methods within the database itself.